@bors try jobs=dist-x86_64-windows-gnu

@bors try jobs=dist-x86_64-mingw

☀️ Try build successful (CI)
Build commit: 104fcc2 (104fcc2a417e55791a997db8b9c3fc0b8885d4d9, parent: e22dab387f6b4f6a87dfc54ac2f6013dddb41e68)

There should only one user observable change from this PR. Passing -Clinker=<linker> when is absent from PATH, will result in an error regarding inability to find <linker>, unless -Clink-self-contained is also provided.
Previously, -Clinker=<linker> allowed to call any executable shipped with Rust, including rust-objcopy, wasm-component-ld.

@petrochenkov
IMO, forbidding to call any Rust shipped binary is clearly a benefit here, but what should we do about -Clinker=x86_64-w64-mingw32-gcc and -Clinker=ld no longer using self-contained mode?
The first one could be handled by an additional sess.opts.cg.linker == sess.target.linker condition (not like that because of different types, but you get the idea). Retaining -Clinker=ld as self-contained without -Clink-self-contained, would unfortunately require hardcoding the name.

allowed to call any executable shipped with Rust, including rust-objcopy, wasm-component-ld

How does it happen?
I'm testing it on x86_64-pc-windows-gnu on master, and it always works, regardless of the self-contained mode.
I don't see what in this PR changes that.

we@DESKTOP-5ALPNIQ MINGW64 ~/rust
$ rustc -Clinker=rust-objcopy ../main.rs

we@DESKTOP-5ALPNIQ MINGW64 ~/rust
$ rustc -Clinker=rust-objcopy ../main.rs -Clink-self-contained=yes

we@DESKTOP-5ALPNIQ MINGW64 ~/rust
$ rustc -Clinker=rust-objcopy ../main.rs -Clink-self-contained=no

Ah, there is a massive hole in my thinking.
So, this PR only stops these shipped binaries being detected as implicit self-contained mode.

"works" is a bit of an overstatement. It produces no error, but doesn't result in a callable binary either. As it turns out, this PR has nothing to do with it.

The same thing happens on Linux, so this is "fine".

Regarding this PR, assuming we want to move decoupling mingw self-contained mode detection forward, do we want to keep -Clinker=<arch>-w64-mingw32-gcc (target's default linker) and -Clinker=ld being detected as implicit self-contained mode?
For the first one, I suppose yes, but I have no idea what to do with bare ld.

I've just noticed that my initial assumption in #147536 (comment) was incorrect, because the linker is not just compared with "rust-lld", but also searched in PATHs.

So maybe just keep things as is?
The heuristic is simple and gives a correct result in non-exotic cases, and in all other cases -Clink-self-contained=yes/no can be used explicitly.

For further simplification the linker == "rust-lld" condition can be removed as redundant, rust-lld never lives in PATH outside of sysroot.

detect_self_contained_mingw and linker_and_flavor don't really have a cyclic dependency, detect_self_contained_mingw always wants the non-self-contained version of the linker for its logic.

detect_self_contained_mingw and linker_and_flavor don't really have a cyclic dependency, detect_self_contained_mingw always wants the non-self-contained version of the linker for its logic.

There was no cyclic dependency there at any point, but it might have looked as such in the previous PR (before reverting changes).
Right now detect_self_contained_mingw depends on linker_and_flavor, but #147536 tried to turn that around, so linker_and_flavor depended on detect_self_contained_mingw.

The problem I'm dealing with is linker_and_flavor either chooses linker from CLI or the spec. Then detect_self_contained_mingw determines whether that linker is self-contained.
The problem arises when target has different linkers for self-contained and normal modes: how linker_and_flavor is supposed to know whether it should use self-contained linker or not? That would result in the mentioned cyclic dependency.
One solution is to flip detect_self_contained_mingw and linker_and_flavor dependency around, although as it turns out it might be not the best one.

Guess we can leave this problem for the future.